@kostaond Thanks taking a look at the emac2emac option. I must say that I concur with your assessment and think that this option is probably not a viable transport option for eppp at this moment.

My suggestion is that we drop the emac2emac option in this PR, but allow the Ethernet init/start functionality to be extended (with callbacks or __weak functions).
Then we can add emac2emac as an example and add appropriate comments about the GPIO0 workaround and the synchronization and reset stuff...

@kostaond Thanks taking a look at the emac2emac option. I must say that I concur with your assessment and think that this option is probably not a viable transport option for eppp at this moment.

My suggestion is that we drop the emac2emac option in this PR, but allow the Ethernet init/start functionality to be extended (with callbacks or __weak functions). Then we can add emac2emac as an example and add appropriate comments about the GPIO0 workaround and the synchronization and reset stuff...

Agree, if you need to move forward, drop the emac2emac. It's currently too much polluted with the GPIO0 workaround. Presence or non presence of the workaround must be super clear to users because the most probable use case is to use ESP32 with WiFi connected to some other chip without WiFi.

It's currently too much polluted with the GPIO0 workaround. Presence or non presence of the workaround must be super clear to users because the most probable use case is to use ESP32 with WiFi connected to some other chip without WiFi.

Removed the emac2emac from the component and added it as an extra example with the specific configuration, so the GPIO0 workaround is in the app code only. (Moreover It demonstrates using any custom Ethernet driver)

@kostaond @euripedesrocha Thanks for your review, I've reworked this PR, so that it uses "just Ethernet" with customizable initialization. Then (in a separate commit) I've added the EMAC-2-EMAC example with all those workarounds and magic delays.

Thanks for your review, Ondrej & Euripedes!